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Abstract 


Industrial  experience  clearly  demonstrates  that  a  product  line  approach  for  software¬ 
intensive  systems  can  save  money  and  result  in  faster  time  to  field  higher  quality  systems. 
Many  within  the  DoD  recognize  the  benefits  of  product  lines,  but  also  recognize  that  there 
are  significant  challenges  to  adopting  this  approach.  Many  of  these  challenges  stem  from  the 
fact  that  the  DoD  is  in  the  business  of  acquiring  systems  rather  than  developing  them. 

A  key  question  is  how  can  a  software  product  line  approach  best  be  accommodated  within 
the  current  DoD  acquisition  environment?  In  order  to  answer  this  question,  this  technical 
note  examines  three  key  DoD  acquisition  policies  and  regulations  and  their  implications  for 
launching  a  product  line  approach.  This  includes  examining  the  DoD  acquisition 
management  process  and  DoD  guidance  on  acquisition  strategies  that  set  the  context  for 
software  product  line  acquisition  planning.  Sources  of  confusing  guidance  on  developing 
acquisition  strategies  are  examined  and  terms  are  defined  to  clarify  what  is  meant  by  a 
product  line  acquisition  strategy.  The  need  for  strategic  acquisition  planning  in  launching  a 
product  line  is  discussed  and  insight  is  provided  on  how  it  differs  from  traditional  acquisition 
planning. 
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1  Introduction 


A  product  line  approach  to  developing  software-intensive  systems  offers  great  promise  for 
delivering  higher  quality  systems  in  a  shorter  time  and  at  reduced  cost  [Bass  97,  Bass  98, 
Bass  99].  While  many  commercial  firms  and  DoD  contractors  are  already  engaged  in  product 
line  practices,  DoD  organizations  are  still  in  the  early  stages  of  determining  how  product 
lines  can  best  be  applied  in  the  DoD  acquisition  environment.  In  this  technical  note,  we 
examine  the  DoD  policies,  regulations,  and  acquisition  management  process  that  govern 
DoD  acquisitions  and  show  how  they  relate  to  product  line  concepts  and  acquisition 
planning. 

A  product  line  is  defined  to  be  a  group  of  products  sharing  a  common,  managed  set  of 
features  that  satisfy  specific  needs  of  a  selected  market  or  mission  [Clements  99b].  It  is  most 
economical  to  build  a  software  product  line  as  a  product  family,  where  a  product  family  is  a 
group  of  systems  built  from  a  common  set  of  assets.  Thus,  when  we  refer  to  a  product  line 
we  always  mean  a  product  line  that  is  implemented  as  a  product  family — i.e.,  one  consisting 
of  a  related  set  of  products  that  share  a  common  architecture  and  are  built  from  a  common 
asset  base. 

Given  this  definition,  there  are  at  least  three  product  line  acquisition  activities  that  need  to  be 
coordinated  in  the  DoD  acquisition  environment.  They  are:  (1)  acquiring  an  architecture  and 
other  elements  of  an  asset  base  to  enable  a  product  line  approach,  (2)  acquiring  software 
products  that  are  developed  using  this  asset  base,  and  (3)  acquiring  the  services  to  maintain 
and  sustain  the  asset  base  while  supporting  the  development  and  enhancement  of  derivative 
systems.  Understanding  how  software  product  line  concepts  align  with  DoD  policies, 
guidance,  and  regulations  will  help  a  DoD  organization  develop  and  implement  a  product 
line  acquisition  strategy1, 2  that  can  support  these  activities.  Toward  this  end,  we  identify  the 
key  policies  and  regulations  and  explore  some  of  their  implications  for  developing  and 
planning  an  acquisition  strategy  for  a  product  line  approach. 


1  Other  factors  such  as  building  a  business  case  for  the  product  line  or  creating  a  funding  model,  which 
may  influence  the  acquisition  strategy,  will  not  be  considered  in  this  technical  note.  They  are 
activities  that  need  to  be  performed  independent  of  whether  or  not  the  product  line  involves 
acquisition. 

2  Acquisition  planning  for  a  product  line  is  also  influenced  by  the  culture  of  the  DoD  workplace. 
Cultural  influences  reflect  the  organizational  values,  management  practices,  and  historical  and 
localized  ways  of  interpreting  and  complying  with  the  regimen  of  policies  and  regulations  that 
govern  the  work  and  the  workforce.  While  these  are  beyond  the  scope  of  this  technical  note,  insight 
into  some  of  these  cultural  influences  on  the  DoD  acquisition  environment  can  be  obtained  from 
[Bergey  98]. 
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2  DoD  Documents  Governing  Acquisition 


Our  focus  is  on  three  documents  that  govern  the  DoD  acquisition  environment: 

•  DoD  Directive  5000.1 

•  DoD  Regulation  5000.2-R 

•  Federal  Acquisition  Regulations  (FAR) 

A  basic  understanding  of  these  documents  is  necessary  to  understand  how  a  software  product 
line  fits  into  the  DoD  acquisition  environment.3  A  brief  overview  of  their  purpose  follows. 

2.1  DoD  Directive  5000.1 

DoD  Directive  5000.1  of  March  15,  1996  is  the  governing  Department  of  Defense  policy 
document  on  “Defense  Acquisition."  This  directive  [DoD  5000.1]  applies  to  all  elements  of 
the  DoD  and  describes  policies  and  broad  management  principles  that  are  applicable  to  all 
DoD  acquisition  programs.  Its  stated  purpose  is  “to  establish  a  disciplined  yet  flexible 
management  approach  for  acquiring  quality  products  that  satisfy  the  operational  user’s 
needs.”  To  govern  the  implementation  of  these  acquisition  policies  and  principles,  DoD 
5000.2-R  was  established. 

2.2  DoD  Regulation  5000.2-R 

DoD  Regulation  5000.2-R  of  1996  specifies  “Mandatory  Procedures  for  Major  Defense 
Acquisition  Programs  (MDAPs)  and  Major  Automated  Information  Systems  (MAIS).”4  Its 
stated  purpose  is  “to  establish  a  simplified  and  flexible  management  framework  for 
translating  mission  needs  into  stable,  affordable,  and  well-managed  programs”  [DoD  5000.2- 
R].  The  regulation  is  organized  into  six  parts  with  six  appendices  and  contains  thousands  of 
specific  requirements  pertaining  to  acquisition  programs.  In  contrast  to  DoD  5000.2-R, 
which  defines  an  overarching  DoD  acquisition  management  process  and  mandatory 
procedures,  the  FAR  regulates  acquisition  planning  and  contracting. 

2.3  Federal  Acquisition  Regulation  (FAR) 

The  FAR  governs  all  acquisition  practices  and  codifies  uniform  policies  and  procedures  to 
regulate  the  acquisition  of  supplies  and  services  by  all  executive  agencies  [FAR  97].  The 
importance  of  the  FAR  is  that  it  is  the  highest  ranking  statutory  document  and  the  common 
denominator  in  every  acquisition  initiated  by  DoD  (or  any  other  executive  agency  of  the 
federal  government,  except  where  expressly  excluded). 


3  These  regulatory  documents  also  apply  to  other  federal  government  agencies  besides  DoD. 

4  The  terms  MDAP  and  MAIS  are  major  system  classifications  defined  in  Part  2  of  DoD  5000.2-R. 
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As  stated  in  DoD  5000.1, 

“If  there  is  any  conflicting  guidance  pertaining  to  contracting,  the  Federal 
Acquisition  Regulation  and/or  Defense  Federal  Acquisition  Regulation 
Supplement  take  precedence  over  DoD  Directive  5000.1  and  DoD  Regulation 
5000.2-R.” 
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3  DoD  Acquisition  Policies  Supporting  Product  Lines 


Software  product  lines  enable  the  achievement  of  many  of  the  stated  goals  in  DoD  policy 
documents.  All  of  the  DoD  5000.1  policies  summarized  in  Table  1  are  compatible  with  a 
product  line  approach  and  the  potential  benefits  that  can  be  realized  with  such  an  approach. 


DoD  5000.1  Policy  and  Abbreviated  Excerpt. 

Section 

POLICY 

“The  primary  objective  of  the  defense  acquisition  system  is  to  acquire  quality 
products  that  satisfy  the  needs  of  the  operational  user  with  measurable  improvements 
to  mission  accomplishment,  in  a  timely  manner,  at  a  fair  and  reasonable  price.” 

D 

Translating  Operational  Needs  Into  Stable,  Affordable  Programs 

Total  System  Approach:  “Acquisition  programs  shall  be  managed  to  optimize  total 
system  performance  and  minimize  the  cost  of  ownership.” 

D.l.e 

Non-Traditional  Acquisition :  “Managers  in  the  acquisition  community  shall  make  use 
of  non-traditional  acquisition  techniques,  such  as  ...  evolutionary  and  incremental 
acquisition,  and  flexible  technology  insertion.” 

D.l.h 

Acquiring  Quality  Products 

Competition:  “Competition  provides  major  incentives  ...  to  enhance  the  application  of 
advanced  technology  as  well  as  a  mechanism  to  obtain  an  advantageous  price.” 

D.2.d 

Innovative  Practices:  “The  Department  encourages  Program  Managers  (PMs)  to 
continually  search  for  innovative  practices  that  reduce  cycle  time,  reduce  cost,  and 
encourage  teamwork.” 

D.2.h 

Continuous  Improvement:  “The  Department  shall  continuously  focus  on  implementing 
major  improvements  necessary  to  streamline  the  acquisition  process,  reduce 
infrastructure,  and  enhance  customer  service  through  process  reengineering  and 
technological  breakthrough.” 

D.2.i 

Software-Intensive  Systems:  “Software  is  a  key  element  in  DoD  systems.  It  is  critical 
that  software  developers  have  a  successful  past  performance  record,  experience  in  the 
software  domain  or  product  line,  a  mature  software  development  process,  and  evidence 
of  use.” 

D.2.k 

Organizing  for  Efficiency  and  Effectiveness 

>  ::::::  i  .V;-'  .  .  ...  "  /■' "-V-  -.V- V  '  .V  ' 

Teamwork:  “Cooperation  and  empowerment  are  essential.  The  acquisition  community 
shall  implement  the  concepts  of  Integrated  Product  and  Process  Development  (IPPD) 
and  Integrated  Product  Teams  (IPTs)  as  extensively  as  possible.” 

D.3.c 

Tailoring:  “Tailoring  may  be  applied  to  various  aspects  of  the  acquisition  process, 
including  program  documentation,  acquisition  phases,  decision  reviews  and  levels.” 

D.3.e 

Table  1:  DoD  5000. 1  Policy  Supporting  a  Product  Line  Approach 
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These  policies  emphasize  DoD  goals  of  affordability,  optimization,  quality,  efficiency,  and 
effectiveness.  These  are  exactly  the  goals  that  organizations  adopting  a  product  line  approach 
have  realized.  Moreover,  the  approaches  being  promoted  by  these  policies  are  highly 
suggestive  of  product  line  practice. 

More  information  on  DoD  acquisition  policies  (and  related  guidance)  is  available  on  the 
acquisition  Web  sites  we  have  listed  in  the  compendium  (Appendix  A)  at  the  end  of  this 
technical  note. 
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4  DoD  Acquisition  Regulations  Related  to  Product  Lines 


Mandatory  procedures  for  acquiring  major  systems5  are  prescribed  in  DoD  5000.2-R.  These 
requirements  will  influence  choices  in  acquisition  planning  for  product  lines.  Despite  the 
comprehensive  size  of  DoD  5000.2-R,  there  are  only  a  relatively  small  number  of 
requirements  that  directly  relate  to  product  lines.6  These  requirements  are  summarized  in 
Tables  2-A  and  2-B  below. 


DoD  5000.2-R  Section  Topic  (Abbreviated  Excerpt) 

Section 

Evaluation  of  Requirements  Based  on  Commercial  Market  Potential 

“In  developing  system  performance  requirements,  DoD  Components  shall  evaluate 
how  the  desired  performance  requirements  could  reasonably  be  modified  to  facilitate 
the  use  of  potential  commercial  or  non-developmental  items,  components,  ? 
specifications,  open  standards,  processes,  technology...”. 

2.3.1 

Open  Systems 

“PMs  shall  specify  open  systems  objectives  and  document  their  approach  for 
measuring  the  level  of  openness  of  systems,  subsystems,  and  components  to  be 
acquired,  and  devise  an  open  systems  strategy  to  achieve  these  requirements.  An  open 
systems  strategy  focuses  on  fielding  superior  warfighting  capability  more  quickly  and 
more  affordably  by  using  multiple  suppliers  and  commercially  supported  practices, 
products,  specifications,  and  standards,  which  are  selected  based  on  performance,  cost, 
industry  acceptance,  long  term  availability  and  supportability,  and  upgrade  potential.” 

3.3.1 

Commercial  and  Non  -Developmental  Items 

“Market  research  and  analysis  shall  be  conducted  to  determine  availability  and 
suitability  of  commercial  and  non-developmental  items  (NDI).” 

3.3.2. 1 

Critical  Product  and  Technology  Competition 

“The  acquisition  strategy  shall  describe  the  approaches  the  PM  will  use  (e.g.,  requiring 
an  open  systems  architecture,  investing  in  alternate  technology  or  product  solutions, 
breaking  out  a  subsystem  or  component,  etc.)  to  establish  or  maintain  access  to 
competitive  suppliers  for  critical  areas  at  the  system,  subsystem,  and  component 
levels.” 

3.3.2.4 

Competition 

“Component  breakout  shall  be  considered  on  every  program  and  shall  be  done  when 
there  are  significant  cost  savings,  when  the  technical  or  schedule  risk  of  furnishing 
government  items  to  the  prime  contractor  is  manageable,  and  when  there  are  no  other 
overriding  Governmental  interests.” 

3.3.5. 1 

Table  2-A:  DoD  5000.2-R  Requirements  Related  to  a  Product  Line  Approach 


5  These  mandatory  procedures  (and  requirements)  are  also  intended  to  serve  as  a  model  for  other 
systems  designated  as  being  non-major  systems. 

6  The  requirements  that  are  cited  represent  a  very  small  part  of  the  entire  regulation  and  should  not  be 
construed  as  being  an  overview  of  DoD  5000.2-R  requirements. 
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DoD  5000.2-R  Section  Topic  (Abbreviated  Excerpt) 

Section 

Best  Practices 

“PMs  shall  avoid  imposing  government-unique  requirements  that  significantly  increase 
industry  compliance  costs.  Examples  of  practices  designed  to  accomplish  this  direction 
include:  open  systems  approach  that  emphasizes  commercially  supported  practices, 
products,  specifications,  and  standards;  best  value  evaluation  and  award  criteria;  use  of 
past  performance  in  source  selection,  results  of  software  capability  evaluations; 
government-industry  partnerships;  and  the  use  of  pilot  programs  to  explore  innovative 
practices.” 

3.35.2 

Open  Systems  Design 

“PMs  shall  address  the  use  of  open  standards  in  the  design  of  all  systems  elements 
(mechanical,  electrical,  software,  etc.).  This  approach  shall  be  followed  to  develop  a 
standards-based  architecture  in  designing  systems.” 

4.3.4 

Software  Engineering 

“Software  shall  be  managed  and  engineered  using  best  processes  and  practices  known 
to  reduce  cost,  schedule,  and  performance  risks; .  ^ 

It  is  DoD  policy  to  design  and  develop  software  systems  based  on  systems  engineering 
principles,  to  include: 

Developing  software  system  architectures  that  support  open  system  concepts; 
exploit  GOTS  computer  systems  products;  and  provide  for  incremental 
improvements  based  on  modular;  reusable,  extensible  software;  Identifying  and 
exploiting  software  reuse  opportunities,  Government  and  commercial.” 

4.3.5 

Interoperability 

“Compatibility,  interoperability  and  integration  are  key  goals  that... shall  be  specified 
and  validated  during  the  requirements  generation  process.  The  DoD  JTA  [Joint 
Technical  Architecture]  is  mandatory  for  all  emerging  systems  and  systems  upgrades.” 

4.3.9 

W ork  Breakdown  Structure  (WBS) 

“A  program  WBS  shall  be  established  that. .  .shall  define  the  total  system  to  be 
developed  or  produced ;  display  the  total  system  as  a  product-oriented  family  tree 
composed  of  hardware,  software,  services,  data,  and  facilities;  and  relate  the  elements 
of  work  to  each  other  and  to  the  end  product.” 

4.4.2 

Integrated  Product  Teams  (IPTs) 

“Working-Level  IPTs  [WIPTs]  shall  focus  on  a  particular  topic  such  as  cost/per¬ 
formance,  test,  or  contracting.  An  Integrating  IPT  shall  coordinate  WIPT  efforts.  The 
PM  shall  form  an  Integrating  IPT  to  support  development  of  strategies  for  acquisition 
and  contracts,  cost  estimates,  evaluation  of  alternatives,  logistics  management,  cost- 
performance  tradeoffs,  etc.” 

5.4, 5.4.2 

Table  2-B:  DoD  5000.2-R  Requirements  Related  to  Product  Line  Approach 


The  significant  aspect  of  these  requirements,  which  apply  to  all  major  system  acquisitions 
and  are  a  model  for  others,  is  that  product  lines  are  inherently  one  of  the  most  effective  ways 
to  realize  them.  Product  line  activities  recommended  by  the  SEI’s  Framework  for  Software 
Product  Line  Practice  [Clements  99b]  are  fully  responsive  to  these  requirements.  They 
include  the  following: 

1.  performing  a  domain  analysis  to  identify  the  commonality  and  variability  across  the 
application  domain  and  establish  requirements  for  the  product  line  architecture  and 
other  components  of  the  asset  base 

2.  conducting  market  research  and  analysis  to  determine  the  availability  of  suitable 
product  line  assets  from  commercial-off-the-shelf  (COTS)  products,  legacy  system, 
or  NDI  sources 


CMU/SEI-99-TN-004 


7 


3.  seeking  product  line  opportunities  (at  the  system,  subsystem,  or  component  level) 
and  establishing  infrastructure  support  to  promote  and  encourage  participation  in 
collaborative  development/acquisition  efforts  among  organizational  units 

4.  providing  specific  guidance  for  building  and  communicating  a  business  case,  and 
developing  a  concept  of  operations  for  how  a  product  line  approach  will  work  in  the 
enterprise7 

5.  developing  an  acquisition  strategy  and  implementing  competitive  contracting 
strategies,  using  performance-based  specifications,  and  preparing  request  for 
proposals  (RFPs)  for  acquiring  product  line  assets  and  derivative  products 

6.  ensuring  the  software  product  line  is  suitably  integrated  with  the  program’s  systems 
engineering  process  and  the  PM’s  open  systems  strategy 

7.  ensuring  the  software  product  line  asset  base  (e.g.,  product  line  architecture,  reusable 
software  components)  and  derivative  products  are  responsive  to  the  system 
requirements  (e.g.,  interoperability)  that  are  allocated  to  software  (at  the  system, 
subsystem,  or  component  level) 

8.  ensuring  mainstream  product  line  activities  (domain  engineering  and  application 
engineering)  and  their  subordinate  tasks  are  reflected  in  a  work  breakdown  structure 
(WBS)  and  appropriately  “rolled-up”  and  integrated  with  the  PM’s  overarching 
“program  WBS” 

9.  forming  IPTs  to  serve  as  a  “virtual”  product  line  organization  to  assist  in  performing 
tasks  such  as  those  identified  above 

These  framework  practices  apply  to  both  DoD  and  industry  (including  DoD  contractors)  and 
are  representative  of  best  practice.  They  are  compatible  with  achieving  conformance  with 
DoD  5000.2-R’s  software-related  requirements — especially  those  relating  to  component 
breakout,  standards-based  architecture,  software  best  practices,  interoperability,  open- 
systems  design,  and  use  of  integrated  product  teams  to  perform  cost  and  schedule, 
performance,  and  risk  tradeoffs. 


7  Product  Line  “Operations”  is  one  of  the  practice  areas  described  in  [Clements  99b], 
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5  DoD  Adoption  of  Product  Lines  and  the  FAR 


There  are  many  similarities  in  applying  a  product  line  approach  in  the  DoD  environment  and 
in  the  commercial  environment.  Examination  of  product  line  practices  and  issues  has  shown 
that  DoD  product  lines  and  industry  product  lines  are  more  alike  than  different  [Bergey  98]. 
From  an  acquisition  standpoint,  though,  there  are  two  basic  differences  between  DoD  and 
industry  product  line  approaches  that  must  be  taken  into  account  in  implementing  a  product 
line. 

One  inherent  difference  is  the  predominant  role  that  acquisition  plays  in  the  DoD 
environment  [Bergey  98].  In  the  commercial  sector,  acquisition  may  also  play  a  significant 
role  (e.g.,  acquiring  COTS  products  or  other  core  assets),  but  it  rarely  applies  to  the  entire 
process  of  acquiring  the  asset  base,  building  derivative  products  using  the  asset  base,  and 
sustaining  both  over  the  life  of  the  deployed  systems.  In  the  DoD  environment,  this  is  closer 
to  the  norm. 

Another  difference  is  that,  in  the  federal  government,  procurement  planning  and  RFP 
development  must  comply  with  the  FAR.  These  regulations  require  government  organizations 
to  follow  a  fixed,  and  sometimes  arduous,  procurement  process  that  spans  RFP  preparation, 
solicitation,  proposal  evaluation,  contract  award,  and  contract  performance  and 
administration.  Other  aspects  of  the  FAR  procurement  system  that  are  peculiar  to  DoD 
acquisition  include  the  following: 

•  ensuring  full  and  open  competition 

•  disclosing  beforehand  the  evaluation  criteria  to  be  used  for  contract  award 

•  permitting  only  performance-based  specifications 

•  choosing  from  a  standard  set  of  items  (called  data  item  descriptions)  to  describe  contract 
deliverables 

•  limiting  contracts  to  a  maximum  of  five  years 

Since  these  requirements  apply  to  all  DoD  acquisitions,  there  are  ramifications  for 
developing  and  implementing  a  software  product  line  acquisition  strategy.  For  example,  if 
one  contractor  develops  all  the  core  assets,  ensuring  full  and  open  competition  for  the 
development  of  follow-on  products  requires  a  strategy  that  addresses  the  issues  of 
“ownership  of  data  rights”  and  “liability”  for  the  assets.  The  implications  of  limiting 
contracts  to  a  maximum  of  five  years  are  more  obvious.  Since  the  typical  life  of  a  product 
line  is  anticipated  to  be  considerably  longer,  the  acquisition  strategy  will  have  to  address 
issues  such  as  ensuring  the  continuity  of  product  line  operations  when  contracts  are  re¬ 
competed. 
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6  DoD  Acquisition  Management  Process  and  Product  Lines 


DoD  5000.2-R  prescribes  a  high-level  acquisition  process  known  as  the  DoD  Acquisition 
Management  Process  to  serve  as  a  framework  for  specifying  mandatory  acquisition 
procedures  and  guide  acquisition  programs.  While  the  DoD  management  process  is  primarily 
directed  towards  major  system  acquisition  programs,  it  is  intended  to  serve  as  a  general 
model  for  all  programs.8  DoD  5000.2-R  acknowledges  that  every  acquisition  is  different  and 
that  a  program  need  not  follow  the  entire  process.  An  acquisition  can  start  anywhere  in  the 
process  as  long  as  risks  are  documented  and  agreed  upon  by  the  PM  and  MDA.  As  shown  in 
Figure  1,  this  acquisition  management  process  is  structured  into  logical  phases  that  are 
separated  by  major  milestone  decisions. 


Figure  1:  DoD  Acquisition  Management  Process 


This  four-phase,  event-driven  management  process  is  intended  to  manage  risks  and  review 
affordability  of  acquisition  programs  on  an  incremental  basis.  Event-driven  means  the 
management  process  is  explicitly  linked  to  decision  points  that  correspond  to  significant 
events  and  demonstrated  accomplishments  in  the  acquisition  life  cycle.  These  events,  or 
decision  points,  are  known  as  milestones.  For  each  major  milestone  there  is  a  prescribed 

PMs  and  milestone  decision  authorities  (MDAs)  for  other  than  non-major  programs  shall  generally 
adhere  to  the  prescribed  process;  however,  they  shall  appropriately  tailor  it  to  best  match  the 
conditions  of  their  individual  programs. 
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decision  criterion  corresponding  to  a  set  of  core  issues.  The  importance  of  this  process  is  that 
it  determines  if  the  program  should  be  approved  and  funded  to  proceed  to  the  next  phase.9 

A  product  line  approach  may  be  adopted  in  any  phase — i.e.,  it  need  not  be  initiated  in  Phase 
0.  For  instance,  many  of  our  DoD  product  line  collaborators  are  starting  a  product  line  in  the 
operational  support  phase.  They  are  strategically  positioned  and  motivated  to  adopt  a  product 
line  approach  by  virtue  of  being  responsible  for  sustaining  and  enhancing  groups  of  very 
similar  operational  systems.  They  have  increased  visibility  into  the  benefits  of  adopting  a 
product  line  and  can  leverage  legacy  system  assets.  And  more  importantly,  they  are  able  to 
quantify  potential  savings.  By  exploiting  the  synergism  a  product  line  approach  offers,  they 
are  creating  a  more  efficient  and  cost  effective  infrastructure  for  developing  new  software 
products  and  performing  life  cycle  support. 

We  expect  this  trend  will  continue,  where  life  cycle  support  organizations  (engaged  in 
enhancing  and  maintaining  a  number  of  similar  but  distinct  systems)  are  the  ones  who  take 
the  initiative  in  starting  a  product  line.  The  number  of  “green  field”  product  lines  (i.e.,  those 
starting  from  scratch)  are  expected  to  be  fewer  in  number.  This  is  due  to  the  prevailing 
“stovepiped”  means  of  funding  development  programs  and  the  lack  of  a  practical  (and 
officially  sanctioned)  means  for  “pooling  funds”  to  consolidate  the  acquisition  of  common 
products  and  services — independent  of  the  life  cycle  phase  (and  color  of  money)  of  the 
participating  projects. 


9  Each  of  these  phases  and  milestones  is  described  in  detail  in  a  novel  acquisition  guide  developed  by 
the  Naval  Air  Warfare  Center  Training  Systems  Division.  The  guide  includes  an  easy-to-navigate 
graphical  roadmap  and  is  available  at  http://www.ntsc.navy.mil/refer/acqguide/acqguide.htm. 
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7  DoD  Acquisition  Strategies  and  Product  Lines 


A  focal  point  of  the  DoD  acquisition  management  process  (Figure  1)  is  the  requirement  for 
developing  an  “acquisition  strategy.”  However,  “acquisition  strategy”  is  a  very  overloaded 
term.  In  DoD  5000.2-R,  for  example,  the  term  “acquisition  strategy”  is  used  interchangeably 
in  reference  to  each  of  the  following: 

•  the  overall  roadmap  for  program  execution  from  program  initiation  through  post-: 
production  support 

•  the  overall  (program)  acquisition  strategy  (covering  the  entire  DoD  acquisition 
management  process) 

•  the  specific  acquisition  strategy  for  one  phase  of  the  acquisition  management  process 

•  the  contracting  strategy  for  how  hardware/software  will  be  purchased 

One  DoD  guidance  document  states  that  “there  is  no  common  working  definition  for  a 
standard  acquisition  strategy,  no  consistent  agreement  on  its  structure  or  composition,  nor 
comprehensive  guidance  on  how  to  develop  and  execute  it”  [Air  Force  96],  While  it  is 
apparent  that  there  is  no  common  understanding  or  agreement,  there  are  sources  (for 
example,  Single  Acquisition  Management  Plan  Guide  [SAMP  96]  and  Acquisition  Document 
Streamlining  Workshop10)  that  provide  more  concrete  guidance11  for  developing  an 
“acquisition  strategy,”  but  even  the  guidance  from  each  of  these  sources  is  different. 

Why  is  there  so  much  confusion  over  “acquisition  strategies”  and  a  lack  of  consensus?  We 
believe  there  are  three  interrelated  reasons.  The  first,  and  most  obvious,  is  that  the  term  is  not 
defined  in  the  DoD  acquisition  policies  and  regulations.  A  second  reason  is  that  acquisition 
strategies  and  program  strategies  are  generally  treated  as  being  synonymous,  as  are  program 
goals  and  acquisition  goals.  Third,  it  is  apparent  that  there  is  not  one  “acquisition  strategy,” 
but  several  tiers  of  “acquisition  strategies”  and,  unfortunately,  the  DoD  policy  and  guidance 
documents  do  not  clearly,  or  consistently,  differentiate  among  them. 

The  question  this  raises  is  how  can  we  sort  through  the  regimen  of  available  guidance  on 
acquisition  strategies  and  appropriately  apply  it  to  a  product  line  approach? 

First,  it  is  important  to  recognize  that  DoD  5000.2-R  views  all  programs  as  being  exclusively 
acquisition  programs.  The  underlying  assumption  is  that  everything  is  being  acquired  and 
nothing  is  being  developed  using  organic  resources.  As  a  result,  DoD  5000.2-R  does  not 
clearly  differentiate  between  a  program  strategy  and  an  acquisition  strategy,  or  between 
program  goals  and  acquisition  goals.  It  treats  them  interchangeably,  even  though  there  are 


10  Training  materials  from  the  Acquisition  Document  Streamlining  Workshop  offered  through  the 
BRTRC  Institute.  For  more  information,  call  BRTRC  at  (703)  205-1593. 

11  This  guidance  is  based  on  established  practices  for  obtaining  approval  of  program  plans  and  funds. 
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significant  differences.  The  bottom  line  is  that  a  large  number  of  programmatic 
considerations  involving  funding  and  program  management  are  included  as  being  an  integral 
part  of  the  acquisition  strategy. 

Next,  we  need  to  define  what  we  mean  by  an  acquisition  strategy.  To  begin,  we  define 
acquisition  as  the  process  of  obtaining  products  and  services  through  contracting.'2  This 
definition,  which  is  consistent  with  both  the  FAR  and  the  SEI’s  Software  Acquisition 
Capability  Maturity  Model®  (SA-CMM®),  serves  as  a  building  block  for  the  following 
definition: 

An  acquisition  strategy  is  a  plan-of-actionfor  achieving  a  specific  goal  or  result  through 
contracting  for  products'3  and  services. 

The  implication  of  this  definition  is  that  an  acquisition  strategy  is  not  “the  overall  roadmap 
for  program  execution.”  Rather,  the  prescribed  DoD  acquisition  management  process, 
depicted  in  Figure  1,  is  “the  overall  roadmap  for  program  execution” — not  the  acquisition 
strategy.  In  our  usage,  acquisition  strategies  are  subordinate  to  this  overarching  process  for 
managing  major  acquisition  programs. 

By  refining  our  more  general  definition,  we  define  a  software  product  line  acquisition 
strategy  as  a  plan-of-action'4  for  achieving  a  specific  product  line  goal  or  result  through 
contracting  for  software  products  and  services.  Accordingly,  a  software  product  line 
acquisition  strategy15  will  differ  from  a  program-level  view  of  an  “acquisition  strategy.”  The 
requirements  DoD  5000.2-R  places  on  a  program-level  “acquisition  strategy”  are  primarily 
directed  towards  major  programs.  The  scope  of  these  requirements  includes  both 
programmatic  and  acquisition  considerations  that  go  far  beyond  contracting  strategies  for  a 
product  line.  This  is  especially  true  for  DoD  organizations  that  choose  to  launch  a  product 
line  on  a  smaller  scale,  or  who  do  not  contract  everything  out,  in  which  case  the  program 
strategy  and  acquisition  strategy  will  clearly  be  different. 


12  Contracting  includes  purchasing,  buying,  commissioning,  licensing,  leasing,  and  procuring  of 
designated  supplies  and  services  via  a  formal  written  agreement. 

*  Capability  Maturity  Model  and  CMM  are  registered  in  the  U.S.  Patent  and  Trademark  Office. 

13  Instead  of  products,  the  FAR  uses  the  term  “supplies”  to  refer  to  tangible  products  and  commodities. 

14  One  that  is  potentially  applicable  to  any  phase  of  the  DoD  acquisition  management  process. 

15  A  product  line  practice  for  “Developing  and  Implementing  an  Acquisition  Strategy”  will  be  described 
in  the  next  release  of  the  SEI’s  Product  Line  Framework. 
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We  will  be  disciplined  about  using  this  definition  to  differentiate  what  we  mean  by  a 
software  product  line  acquisition  strategy  from  DoD  5000.2-R’s  use  of  the  term.  This  will 
lay  the  foundation  for  describing  product  line  acquisition  strategies  that  programs  can  adapt 
to  meet  their  specific  needs — independent  of  what  particular  acquisition  phase  (Figure  1) 
they  may  be  in.  This  conceptual  approach  does  not  preclude  anyone  from  suitably  “rolling 
up”  the  selected  software  product  line  acquisition  strategy  and  integrating  it  with  a  higher- 
tier  strategy  such  as  the  PM’s  overall  “acquisition  strategy”  at  the  program  planning  level. 
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8  Product  Line  Acquisition  Planning 


All  the  DoD  documents  stress  the  need  for  acquisition  planning.  They  recognize  that  proper 
planning  is  key  to  satisfying  the  system  requirements  and  to  ensuring  a  successful 
acquisition.  Since  product  lines  are  more  complex  and  require  strategic  thinking,  planning  is 
even  more  critical.  Choosing  to  adopt  a  product  line  approach  is  a  long  term  decision.  It 
involves  strategic  planning  to  coordinate  multiple  projects  for  the  long-range  acquisition  of  a 
family  of  software  systems. 

Acquisition  planning  and  acquisition  strategies  are  pivotal  to  DoD  adoption  of  a  product  line 
approach.  We  need  to  differentiate  between  an  acquisition  strategy  and  an  acquisition  plan. 
An  acquisition  plan  is  the  artifact  that  is  typically  used  to  document  the  overall  acquisition 
strategy,  but  the  main  thrust  of  the  plan  is  to  describe  how  the  acquisition  strategy  is  going  to 
be  implemented  from  a  contractual  standpoint.  This  is  consistent  with  good  practice  and  the 
FAR,  which  emphasizes  contracting  strategies  and  requires  a  plan  for  all  acquisitions. 

Developing  an  effective  software  product  line  acquisition  strategy  involves  planning  at 
several  levels.  As  shown  in  Figure  2,  the  acquisition  planning  typically  involves  the  parent 
program(s),  participating  projects,  the  designated  organization  responsible  for  implementing 
and  sustaining  the  product  line,  and  supporting  teams  involving  key  stakeholders.  As  the 
figure  indicates,  more  planning  details  are  required  as  the  work  progresses  further  down  the 
organizational  chain. 


Figure  2:  Organizational  Elements  Involved  in  Product  Line  Acquisition  Planning 

Since  software  product  lines  require  strategic  acquisition  planning  that  complements  the 
strategic  mission  planning,  adoption  may  affect  both  program  and  project  planning.  The 
degree  to  which  these  organizational  elements  are  involved  in  acquisition  planning  will  vary 
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based  upon  the  specific  product  line  approach  that  is  chosen  and  the  scope  of  the  product 
line. 

Key  elements  of  the  acquisition  strategy  and  the  supporting  planning  revolve  around  one  or 
more  of  the  following  types  of  contracting  activities: 

•  acquiring  a  software  architecture,  common  software  components,  and  other  elements  of 
the  asset  base  needed  to  enable  a  product  line  approach 

•  acquiring  software  products  (at  the  system,  subsystem,  or  component  level)  that  are 
developed  from  this  asset  base 

•  acquiring  services  to  manage,  maintain,  and  sustain  the  asset  base  and  provide  the 
infrastructure  support  needed  to  assist  projects  (and  users)  engaged  in  modifying, 
assembling,  instantiating,  or  generating  multiple  products  using  the  asset  base 

A  key  aspect  of  product  line  acquisition  planning  is  establishing  the  most  effective 
contracting  means  (in  accordance  with  the  FAR)  for  implementing  the  selected  software 
product  line  acquisition  strategy.  This  will  include  determining 

•  the  number  and  types  of  contracts  needed  to  meet  the  acquisition  goals  and  objectives 

•  how  continuity  of  contractual  products  and  services  can  best  be  sustained  over  the 
projected  life  of  the  product  line  and  participating  projects 

•  the  detailed  strategy  for  each  contract,  including  answers  to  the  following  questions: 

—  What  should  be  specified  in  the  RFP? 

-  What  should  be  included  in  the  statement  of  work  (SOW)? 

—  What  should  be  the  basis  for  the  technical  evaluation  criteria? 

-  What  kinds  of  incentives  are  appropriate? 

-  What  deliverables  should  be  included? 

-  What  data  rights  should  be  incorporated? 

How  is  the  contractual  approach  for  implementing  a  software  product  line  different?  It  will 
typically  involve  multiple  contracts,  participation  by  multiple  projects,  close  coupling  and 
coordination  of  deliverables,  interim  deliverables  and  checkpoints  to  accommodate  iteration 
in  product  line  activities,  and  provisions  in  RFPs  and  SOWs  to  reflect  accepted  product  line 
practice.  Developing  and  implementing  an  acquisition  strategy  is  an  identified  product  line 
practice  described  in  the  SEI’s  Framework  for  Software  Product  Line  Practice  [Clements 
99b]. 
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9  Summary 


We  have  reviewed  the  key  documents  that  govern  DoD  acquisition  to  (1)  identify  the 
policies,  regulations,  and  processes  that  pertain  to  software  product  lines,  (2)  clarify  their 
relationship  to  product  line  concepts,  (3)  understand  their  implications  for  launching  a 
product  line,  and  (4)  understand  the  role  they  will  play  in  developing  a  product  line 
acquisition  strategy  and  in  acquisition  planning.  The  following  points  summarize  our 
findings  and  conclusions. 

1 .  A  product  line  approach  is  compatible  with  DoD  acquisition  policies.  Both  share  the 
same  high-level  goals  and  product  lines  offer  a  viable  means  of  achieving  them. 

2.  The  acquisition  regulations  include  only  a  small  number  of  requirements  that  directly 
pertain  to  software.  A  product  line  approach  is  not  only  compatible  with  all  of  these 
requirements,  but  represents  a  unifying  and  effective  solution  approach  for  complying 
with  them.  Moreover,  the  product  line  practices  described  in  the  SEI’s  Product  Line 
Framework  are  consistent  with  meeting  these  requirements. 

3.  The  FAR  imposes  some  unique  acquisition  requirements  on  DoD  and  federal 
government  organizations  and  closely  regulates  the  pre-award  contracting  process.  None 
of  the  constraints  are  “show-stoppers,”  but  they  have  to  be  suitably  taken  into  account  in 
acquisition  planning. 

4.  The  DoD  acquisition  management  process  is  oriented  towards  building  major,  one-of-a- 
kind  systems  from  the  ground  up.  However,  nothing  precludes  adopting  a  product  line 
approach  in  any  phase  of  the  process  and  suitably  tailoring  the  process. 

5.  DoD  5000.2-R  imposes  many  program-level  “acquisition  strategy”  requirements  that  are 
above  and  beyond  what  might  be  needed  for  a  software  product  line  acquisition  strategy. 
This  situation  is  resolvable  by  appropriately  defining  an  acquisition  strategy  and  clearly 
differentiating  between  program  goals  and  acquisition  goals  (and  program  strategies  and 
acquisition  strategies). 

6.  Acquisition  planning  will  be  a  critical  element  in  launching  a  product  line.  It  involves 
strategic  planning  commensurate  with  the  scope  of  the  product  line,  the  vision  for 
product  line  operations,  and  the  projected  number  of  products  and  core  assets  that  are  to 
be  developed  and  sustained  over  the  life  of  the  product  line. 


CMU/SEI-99-TN-004 


17 


Appendix  A:  Compendium  of  Acquisition  Related  Web  Sites 


WEB  SITE  DESCRIPTION 

Defense  Acquisition  Revolution  Office  of  Deputy  Under  Secretary  of  Defense  (DUSD) 

www.acq.osd.mil/ar/  for  Acquisition  Reform  (AR)  sponsors  this  Web  site. 

Collects  pertinent  information  dealing  with  the  Defense 
Acquisition  Revolution  including  the  topics  listed  below: 

www.acq.osd.mil/ar/#hot  Latest  Topics  in  Acquisition  Reform: 

I  Upcoming  Events  I  AR  In  the  News 

www.acq.osd.miI/ar/#org  DUSD(AR)  Organization 

Organizational  breakout  for  Acquisition  Reform  Office 

www,acq.osd.mil/ar/#activities  AR  Topics: 

Initiatives  I  PATs  I  Working  Groups  I  Focus  Groups  I 
Miscellaneous 

www.acq.osd.mil/ar/#library  Reference  Library: 

Laws  1  Regulations  (FAR)  I  Directives  (5000  Series)  I 
Acquisition  Deskbook  I  Periodicals  I  Success  Stories  I  • 
Other  (Policy  docs.  Speeches,  etc.).  Includes  links  to  the 
FAR,  DoD  5000.1,  and  DoD  5000.2-R. 

www.acq.osd.mil/ar/#sites  Other  AR  Sites: 

A  comprehensive  listing  of  acquisition  links  available  on  the 
Web.  Includes  links  to  education  and  training,  and  Air 
Force,  Array,  and  Navy  acquisition  sites. 

MIL-STD-881B,  Work  Breakdown  Structures  MIL-HDBK-88 1  provides  a  consistent  and  visible 
; www .acq.osd.mil/pra/newpolicy/wbs/wbs.html  framework  for  defense  materiel  items  and  contracts  within  ' 

a  program  to  promote  improved  communication  throughout 
the  acquisition  process. 

These  guidelines  cover  the  gamut  of  software-intensive 
systems  acquisition  and  management  activities,  from  pre¬ 
program  strategic  planning  to  post-deployment  software  ■ 
support.  They  are  divided  into  three  essential  areas  for 
program  success.  Part  I,  Introduction,  lays  the  groundwork*  : 
Part II,  Engineering,  provides  the  meat.  Partin, 
Management,  brings  it  all  together-  . -'V',.- 

SEPs  Software  Acquisition  Capability  Maturity  The  SA-CMM  is  a  model  for  benchmarking  and 
Model  (SA-CMM)  the  software  acquisition  process.  The  model  follows 

^^^ei-cniu.edu/ajm/SA-CMM.html  the  same  architecture  as  the  Capability  Maturity  Model  for 

Software  (SW-CMM),  but  with  a  unique  emphasis  on 
acquisition  issues  and  the  needs  of  individuals  and 
groups  who  are  planning  and  managing  software 
acquisition  efforts.  Each  maturity  level  indicates  an 
acquisition  process  capability  and  has  several  key  process 
areas  (KPAs).  Each  KPA  has  goals  and  common  features 
and  organizational  practices  intended  to  institutionalize 
.'V:?.'  common  practice. 

Federal  Acquisition  Virtual  Library  Provides  links  to  numerous  other  federal  acquisition 

! www.amet.gov/references/references.html  resources  on  the  Web. 


STSC’s  Guidelines  for  Successful  Acquisition 
Management  of  Software-Intensive  Systems 

www.stsc.hill.af.mil/stscguid.html 


18 


CMU/SEI-99-TN-004 


References 


[Air  Force  96] 

[Bass  97] 

[Bass  98] 

[Bass  99] 

[Bergey  98] 

[Clements  99a] 

[Clements  99b] 

[DoD  5000.1] 


Guidelines  for  Successful  Acquisition  and  Management  of  Software- 
Intensive  Systems,  Chapter  12  [online].  Department  of  the  Air  Force, 
Software  Technology  Support  Center,  September  1996.  Available  WWW: 
<URL:  http://www.stsc.hill.af.mil/stscguid.html>. 

Bass,  Len;  Clements,  Paul;  Cohen,  Sholom;  Northrop,  Linda;  &  Withey, 
James.  Product  Line  Practice  Workshop  Report  (CMU/SEI-97-TR-003, 
ADA327610).  Pittsburgh,  Pa.:  Software  Engineering  Institute,  Carnegie 
Mellon  University,  1997. 

Bass,  Len;  Chastek,  Gary;  Clements,  Paul;  Northrop,  Linda;  Smith,  Dennis; 
&  Withey,  James.  Second  Product  Line  Practice  Workshop  Report 
(CMU/SEI-98-TR-015,  ADA354681).  Pittsburgh,  Pa.:  Software  Engineering 
Institute,  Carnegie  Mellon  University,  1998. 

Bass,  Len;  Campbell,  Grady;  Clements,  Paul;  Northrop,  Linda;  &  Smith, 
Dennis.  Third  Product  Line  Practice  Workshop  Report  (CMU/SEI-99-TR- 
003).  Pittsburgh,  Pa.:  Software  Engineering  Institute,  Carnegie  Mellon 
University,  1999. 

Bergey,  John,  et  al.  DoD  Product  Line  Practice  Workshop  Report 
(CMU/SEI-98-TR-007,  ADA346252).  Pittsburgh,  Pa.:  Software 
Engineering  Institute,  Carnegie  Mellon  University,  1998. 

Clements,  Paul.  “Software  Product  Lines:  A  New  Paradigm  for  the  New 
Century.”  Crosstalk  12, 2  (February  1999):  20-22. 

Clements,  Paul  &  Northrop,  Linda.  A  Framework  for  Software  Product  Line 
Practice,  Version  1.1  [online].  Pittsburgh,  Pa.:  Software  Engineering 
Institute,  Carnegie  Mellon  University,  March  1999.  Available  WWW: 
<URL:  http://www.sei.cmu.edu/plp/framework.html>. 

DoD  Directive  5000.1,  Defense  Acquisition  [online].  U.S.  Department  of 
Defense,  March  1996.  Available  WWW: 

<URL:  http://www.acq.osd.mil/api/asm/product.html>. 


CMU/SEI-99-TN-004 


19 


[DoD  5000.2-R] 

[FAR  97] 

[SAMP  96] 


DoD  Regulation  5000.2,  Mandatory  Procedures  for  Major  Defense 
Acquisition  Programs  (MDAPs)  and  Major  Automated  Information  System 
(MAIS)  Acquisition  Programs  [online],  U.S.  Department  of  Defense, 
October  6,  1997  (date  of  Change  2).  Available  WWW: 

<URL:  http://www.acq.osd.mil/api/asm/product.html>. 

Federal  Acquisition  Regulation,  FAC  97  [online],  October  10,  1997. 
Available  WWW:  <URL:  http://www.amet.gov/far/index.htm>. 

Single  Acquisition  Management  Plan  (SAMP)  Guide  [online].  Available 
WWW:  <URL:  http://www.safaq.hq.af.mil/acq_ref/bolts/bolt7/>. 


20 


CMU/SEI-99-TN-004 


Acknowledgments 


We  especially  want  to  acknowledge  the  contribution  of  Linda  Northrop  and  Brian  Gallagher 
who  provided  insightful  comments  and  suggestions  for  this  technical  note. 


CMU/SEI-99-TN-004 


21 


Feedback  and  Contact 


SEI  Technical  Notes  on  Business  and  Acquisition  Guidelines 
for  Product  Lines 

Comments  or  suggestions  about  this  document  or  the  series  of  technical  notes  on  software 
product  line  business  and  acquisition  guidelines  are  welcome.  We  want  this  series  to  be 
responsive  to  the  needs  of  DoD  and  government  personnel  involved  in  the  business  and 
acquisition  aspects  of  implementing  software  product  lines.  To  that  end,  comments 
concerning  this  technical  note,  inclusion  of  other  topics,  or  any  other  issues  or  concerns  will 
be  of  great  value  in  continuing  this  series.  Comments  or  suggestions  should  be  sent  to 

Linda  Northrop,  Director 
Product  Line  Systems  Program 
lmn  @  sei.cmu.edu 

Software  Engineering  Institute 
Carnegie  Mellon  University 
Pittsburgh,  PA  15213 


22 


CMU/SEI-99-TN-004 


REPORT  DOCUMENTATION  PAGE 

Form  Approved 

OMB  No.  0704-0188 

Public  reporting  burden  for  this  collection  of  information  is  estimated  to  average  1  hour  per  response,  including  the  time  for  rev.ew.ng  instructions,  search. ng  ex.st.ng  data isources,  gathering 
and  maintaining  the  data  needed,  and  completing  and  reviewing  the  collection  of  information.  Send  comments  regarding  this  burden  estimate  or  any  other  aspect  of  this  collection  of 
information,  including  suggestions  for  reducing  this  burden,  to  Washington  Headquarters  Services,  Directorate  for  information  Operations  and  Reports,  1215  Jefferson  Dav.s  Highway,  Suite 
ion*  AH!,,,-*™  va  Ain?  anH  to  the  Office  of  Management  and  Budget,  Paperwork  Reduction  Project  (0704-0188),  Washington,  DC  205Q3. - - - *— - 

1 .  AGENCY  USE  ONLY  (LEAVE  BLANK) 

2.  REPORT  DATE 

May  1999 

3.  REPORT  TYPE  AND  DATES 

COVERED 

Final 

4.  TITLE  AND  SUBTITLE 

The  DoD  Acquisition  Environment  and  Software  Product  Lines 

5.  FUNDING  NUMBERS 

C  —  FI  9628-95-C-0003 

6.  AUTHORfS) 

John  K.  Bergey,  Matthew  J.  Fisher,  Lawrence  G.  Jones 

7.  PERFORMING  ORGANIZATION  NAME(S)  AND  ADDRESS(ES) 

Software  Engineering  Institute 

Carnegie  Mellon  University 

Pittsburgh,  PA  15213 

8.  PERFORMING  ORGANIZATION 

REPORT  NUMBER 

CMU/SEI-99-TN-004 

9.  sponsoring/monitoring  agency  name(s)  and  ADDRESS(ES) 

HQ  ESC/DIB 

5  Eglin  Street 

Hanscom  AFB,  MA  01 731  -21 1 6 

1 0.  SPONSORING/MONITORING 

AGENCY  REPORT  NUMBER 

1 1 .  SUPPLEMENTARY  NOTES 

12.A  DISTRIBUTION/AVAILABILITY  STATEMENT 

Unclassified/Unlimited,  DTIC,  NTIS 

12.B  DISTRIBUTION  CODE 

1 3.  ABSTRACT  (MAXIMUM  200  WORDS) 

Industrial  experience  clearly  demonstrates  that  a  product  line  approach  for  software-intensive  systems  can  save 
money  and  result  in  faster  time  to  field  higher  quality  systems.  Many  within  the  DoD  recognize  the  benefits  of 
product  lines,  but  also  recognize  that  there  are  significant  challenges  to  adopting  this  approach.  Many  of  these 
challenges  stem  from  the  fact  that  the  DoD  is  in  the  business  of  acquiring  systems  rather  than  developing  them. 

A  key  question  is  how  can  a  software  product  line  approach  best  be  accommodated  within  the  current  DoD 
acquisition  environment?  In  order  to  answer  this  question,  this  technical  note  examines  three  key  pop 
acquisition  policies  and  regulations  and  their  implications  for  launching  a  product  line  approach.  This  includes 
examining  the  DoD  acquisition  management  process  and  DoD  guidance  on  acquisition  strategies  that  set  the 
context  for  software  product  line  acquisition  planning.  Sources  of  confusing  guidance  on  developing  acquisition 
strategies  are  examined  and  terms  are  defined  to  clarify  what  is  meant  by  a  product  line  acquisition  strategy. 

The  need  for  strategic  acquisition  planning  in  launching  a  product  line  is  discussed  and  insight  is  provided  on 
how  it  differs  from  traditional  acquisition  planning. 

14.  SUBJECT  TERMS 

acquisition,  Department  of  Defense,  policies,  product  lines,  software  acquisition, 
regulations 

15.  NUMBER  OF  PAGES 

22  pp. 

16.  Price  Code 

17.  SECURITY  CLASSIFICATION  18.  SECURITY  CLASSIFICATION 

OF  REPORT  OF  THIS  PAGE 

UNCLASSIFIED  UNCLASSIFIED 

19.  SECURITY  CLASSIFICATION 

OF  ABSTRACT 

UNCLASSIFIED 

20.  LIMITATION  OF  ABSTRACT 

UL 

Standard  Form  298  (Rev.  2-89) 

